In network transactions, a certificate authority (“CA”) is an entity that issues digitally signed certificates (“digital certificates”) to other entities such as organizations or individuals to allow them to prove their identity to others in financial or other remote transactions. A certificate authority may be an external company such as one which offers digital certificate services, or may be an internal organization such as a corporate MIS department. The certificate authority's chief function is to ascertain whether a subscriber meets the policy criteria for a class of digital certificates and if so, to issue one. A “subscriber” could be a person, a machine, or an executable.
At present, for financial transactions, online customers obtain a digital certificate from a certificate authority or their bank, and send that digital certificate with a signed transaction request (e.g., purchase order) to a merchant. The merchant typically verifies the customer's signature using the public key in the certificate and in the process assures that the digital certificate's status is valid (e.g., not revoked). The X.509 standard (ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 Dec. 1996) specifies that a way to determine the status of a digital certificate is by using a certificate revocation list (“CRL”). Each certificate authority (or its designated agent) publishes a CRL of digital certificates it has previously issued that are now revoked. The merchant downloads the CRL from the issuing certificate authority and searches the list to make sure that the serial number of the digital certificate in question is not on the list.
CRLs cause a variety of problems, one of which is that that the list of all revoked certificates from the certificate authority may potentially become very large. More importantly, a CRL may not be sufficiently current, (i.e. “fresh enough”), whereby reliance thereon creates unacceptable financial risk. This “freshness problem” is particularly dangerous in high-value transactions.
A merchant may also verify a digital certificate by utilizing an Online Certificate Status Checking Protocol (“OCSP”), a presently proposed standard by which the certificate authority or a verification company makes an independent assertion about a digital certificate's validity. With OCSP like other insurance schemes, financial risk is purposely assumed by the certificate authority or verification company in exchange for a per-transaction fee. The certificate authority or verification company determines if the digital certificate is revoked, and returns a good, revoked or unknown status.
While OCSP is thus potentially more up-to-date than CRL-based solutions, OCSP has a number of economically-motivated peculiarities and limitations that make it less than ideal for many transactions. For example, an OCSP response is essentially an up-to-date one-certificate CRL, returning only either the good, revoked or unknown assertion about a certificate in an entirely new message format. Moreover, OCSP presumes a particular risk management pricing model that attaches a high cost and high liability to the issuance of every certificate status assertion. As such, OCSP depends upon its own three-tier (Client-Certificate Authority-Designated Responder) infrastructure, wherein the number of qualified certificate issuers and designated status responders is highly limited. In typical financial transactions, however, acceptance policy is up to the policy of the party buying the risk, and there is no reason to limit the parties to transactions to the narrow OCSP model, let alone to the simplistic certificate status assertion of good, revoked or unknown.